Service-oriented architecture (SOA) is a design paradigm for computing systems. It is based around an abstract model in which computing resources are considered in terms of needs and capabilities. In such a model, a service is an entity which is made available to a service-client, to fulfill one or more needs of the client. A core principle of SOA is that services are loosely coupled: that is, different services can be provided by different providers, potentially distributed at different physical locations or points in a computer network. Thus, services are not provided in fixed, monolithic groupings (as is often the case with legacy software applications) but, instead, a service-client can draw together the particular group of services that best fits its needs. The SOA model can be particularly beneficial when it is desired to integrate diverse computing functions—for example, several different computing functions used in a business. In this case, the SOA paradigm can lead to a reduction in redundancy, and resulting decreased commissioning and maintenance costs—for example, because common tasks such as log-in or authentication are implemented just once and then shared as a service (or set of services), instead of being provided independently in several separate software applications.
The potential improvements in efficiency and flexibility offered by SOA are great. However, the openness and interoperability demanded by such a software-architecture places additional demands on the designers of computer systems. It is desirable that an organization retains adequate control of software components made available as services, despite their open availability on a network, for example. This leads to a concept of a “managed service”, which is made available for service-clients to use, but is managed according to a runtime policy. This runtime policy ensures that the overall business policy of an organization is obeyed. It is the practical implementation of the principles contained in the business policy.
Responsibility for enforcing runtime policies falls on Policy-Enforcement Points (PEP). These are points in the system architecture which can act as gateways to the services. Thus, a client wishing to access a service does so via a policy enforcement point, which enforces the runtime policy for that service. A contract is formed when one party to a service-oriented interaction agrees to adhere to the policies of another.